Bluetooth: AVRCP: connection and disconnection of AVRCP #75637
Conversation
zephyrbot
added
area: Bluetooth Classic
zephyrbot
requested review from
alwa-nordic,
asbjornsabo,
hermabe,
jhedberg,
jori-nordic,
lylezhu2012,
nashif,
sjanc,
tejlmand,
Thalley,
theob-pro and
Vudentz
gzh-terry
force-pushed
the
fea_avrcp
branch
2 times, most recently
from
7126a1d
to
6c6aab4
Compare
|
Hi @lylezhu2012 , May I doublecheck if this is the correct method to start a new feature? Best regards, |
@gzh-terry thanks for your PR. Yes, this is fine, you can submit a part of the implementation in a first Pull Request and then later send follow-up PRs with additional functionality. |
| if (IS_ENABLED(CONFIG_BT_AVCTP)) { | ||
| bt_avctp_init(); | ||
| } | ||
|
|
||
| bt_sdp_init(); | ||
|
|
||
| if (IS_ENABLED(CONFIG_BT_A2DP)) { | ||
| bt_a2dp_init(); | ||
| } | ||
|
|
||
| if (IS_ENABLED(CONFIG_BT_AVRCP)) { | ||
| bt_avrcp_init(); | ||
| } |
There was a problem hiding this comment.
This isn't particularly scalable. It should be possible to implement new profiles/protocols completely on the application side, which means that you can't have a requirement that the stack-internal l2cap_br.c needs to be modified every time you add some new profile. The profiles/protocols which are part of the Bluetooth core specification (L2CAP, SDP, etc) could be treated as an exception, but for everything else you need to find a solution which doesn't require modifying this internal c-file.
There was a problem hiding this comment.
I'm not quite sure why A2DP and AVDTP is placed here.
Nevertheless, we should put them together rather than write AVRCP elsewhere.
gzh-terry
force-pushed
the
fea_avrcp
branch
9 times, most recently
from
16fbc1e
to
7dfbae4
Compare
This patch implementing avrcp.c New Kconfig BT_AVRCP is provided to enable this layer. BT_AVRCP_TARGET and BT_AVRCP_CONTROLLER are then provided to enable one of the two roles independently. avrcp.h shows the APIs for the upper layer. Only connection and disconnection interfaces are provided in this patch. Signed-off-by: Zihao Gao <[email protected]>
This patch add SDP records for both CT and TG role. The SDP attribute would be registered according to the configuration. OBEX and Browsing commands are optional and yet not supported. SDP registration is implemented at AVRCP level to simplify the workload of the upper layer. We assume the App can have limited knowledge on SDP structures. Signed-off-by: Zihao Gao <[email protected]>
Only the basic functions for establishing an AVCTP connection are provided at this stage. An BR/EDR ACL connection is necessary before AVRCP function. Register callbacks before utilizing AVRCP. Signed-off-by: Zihao Gao <[email protected]>
This patch defines the message format for general AVCTP. They would be further called by AVRCP layer. Signed-off-by: Zihao Gao <[email protected]>
This patch defines the message format for AVCTP unit message. This is the first out of the four types of commands and can be used by the CT to obtain the unit info from the TG device. Signed-off-by: Zihao Gao <[email protected]>
This patch allow to acquire the unit info of the remote device. Signed-off-by: Zihao Gao <[email protected]>
This patch received an AVCTP message and forward to the upper layer, e.g., AVRCP. Signed-off-by: Zihao Gao <[email protected]>
This patch received an AVRCP message and remove timeout timers. Signed-off-by: Zihao Gao <[email protected]>
|
Hi @jhedberg, Many appreciates for your quick review. |
The bit order can be incorrect when use bit field definition. Signed-off-by: Zihao Gao <[email protected]>
This pull request implemented the basic AVRCP functions, which includes:
This is the first part of the entire AVRCP functions, we tested the code by
establishing AVCTP channel with Android phones.
Four configs are provided to turn on/off the functions: